【ざっくり解説】Route 53 ResolverとResource Access Managerについて3段階で図解説する

今回のテーマ

こんにちは「ハンターハンター38巻を待ち望んでいる」AWS事業本部コンサルティング部のこーへいです。

今回のテーマは「Route 53 Resolver」と「Resource Access Manager」についてです。

テーマの目的

最近「Route 53 Resolver」という存在を知り、加えてRoute 53 Resolver Ruleを「Resouce Access Manager」で共有するとルールの一元管理で便利になると知りました。

以下の記事を参考にしつつ、お絵描きするとようやく自分向けの理解しやすいものが出来たので共有しようという目的です。

あくまで概念的な解説が目的ですので詳細な説明は省略し、理解しやすい土壌作りをメインに扱っていきます。

第1段階 Route 53 Resolver

まずはRoute 53 Resolver単体で見てましょう。

今回のケースでは単一VPC内にて、Route 53 プライベートホストゾーンを用いて名前解決したい状況を想定しています。

Route 53 ResolverはVPC内にてデフォルトで存在するフォワーダーとしての機能を持つDNSサーバーで、名前解決を行うネームサーバー(今回はRoute 53 プライベートホストゾーン)へ通信を転送する機能を持っています。

第2段階 Route 53 Resolver エンドポイント

次はオンプレミス環境とクラウド環境のハイブリッド構成にて、オンプレミス内にあるサーバーがクラウド内にあるネームサーバー(今回はRoute 53 プライベートホストゾーン)で名前解決を行いたい状況を想定して解説します。

このようなケースに必要になってくるのがRoute 53 Resolver インバウンドエンドポイントです。

図では通信元サーバーをオンプレミス環境、ネームサーバー(Route 53 プライベートホストゾーン)と通信先サーバーをクラウド環境に配置しています。

その場合、Route 53 Resolver インバウンドエンドポイントを使用しないとオンプレミスからクラウド環境にあるフォワーダー(Route 53 Resolver)にクエリ処理を送信できず、Route 53 プライベートホストゾーンに転送できないため名前解決を行えません。

そこで、Route 53 Resolver インバウンドエンドポイントを立てることでエンドポイント経由でRoute 53 Resolverにクエリ処理を送ることができるようになり、Route 53 プライベートホストゾーンに転送できるようになるので名前解決が可能となります。

第3段階 Route 53 Resolver RuleとResource Access Manager

最後に以下のケースについて解説します。

• クラウド環境に存在するサーバーから、オンプレミスのネームサーバーで名前解決を行いたい
• 上記クラウド環境が複数あるとき

上記の図では、クラウド環境内にある通信元サーバーからフォワーダー(Route 53 Resolver)へ、次にRoute 53 Resolver アウトバウンドエンドポイントを経由し、オンプレミスに存在するネームサーバーにクエリ処理を転送し、名前解決を行なっています。

しかし、オンプレミス環境内のネームサーバーにて名前解決を行うためには、AWS側でフォワーダーの転送ルール(Route 53 Resolever Rule)を定義しなければなりません。

転送ルールとは、図の赤字部分のRoute 53 Resolverがどのネームサーバーを参照するかのルールのことを指します。

その転送ルールを他のAWSアカウントに共有し、対象のVPCに紐づけることで各アカウント毎にRoute 53 Resolever Ruleを作成しなくても、Route 53 Resolverがどのネームサーバーで名前解決を行えばいいかが設定できます。

まとめ

こうしてみると意外と難しくなかったのではないでしょうか？

より詳細な理解には、BlackBeltの資料がすごくわかりやすいので参照してみてください。

• DNSサーバー(オンプレミスやRoute 53のホストゾーン)
• Route 53 Resolver (AmazonProvidedDNS)
• Route 53 Resolver エンドポイント
• Route 53 Resolver Rule

コツとしては上記4つの役割を意識しながら、通信の流れを確認してみると理解が進むと思います！